Date: Mon, 18 Jan 93 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>
Errors-To: Packet-Radio-Errors@UCSD.Edu
Reply-To: Packet-Radio@UCSD.Edu
Precedence: Bulk
Subject: Packet-Radio Digest V93 #17
To: packet-radio


Packet-Radio Digest         Mon, 18 Jan 93       Volume 93 : Issue   17

Today's Topics:
                                (none)
                          BAYCOM and Linux ?
                Problems using ka9q and activeopen PPP
                  rsgb gb2rs news 17th november 1993
             TS140s, MFJ Multimode TNC and LSB Distortion
                      USING HANDHELDS ON PACKET
                   Writing a packet client program?

Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 17 Jan 93 22:51:49 GMT
From: news-mail-gateway@ucsd.edu
Subject: (none)
To: packet-radio@ucsd.edu

Quent Johnson  (quent@md.fsl.noaa.gov) said:

What if someone sends email containing obscenities.
What about sound files containing music?
What about email to mailing lists -- is this considered broadcasting?

I say:

I'm sure the control op eithe inspects the mail (unlikely) or has a 
kill file that looks for "obsscene, indecent, or profane words" in the 
text and doesn't allow transmission if it finds one. The full part of 
97.113(d) goes futher than this though: obsscene, indecent, or profane 
words or meaning [it might be difficult to stop the later with a kill 
file is only 'clean' words are used]; and/or false or deceptive 
messages or signals [this too are more difficult to detect]". Once must 
also be wary of commerical messages (i.e look for the string "900" :-). 
THe FCC did backoff on the responsibilities of sysops who relayed 
messages in the system, the originator having the full responsibility. 
Unfortunatly the control operator of the gateway is the responsible 
person in this case. This may explain why there are very few gateways.

Data files containing musical sounds are only musical sounds when 
played on the appropriate equipment. They don't sound like music on the 
air (just sound like packets too me) so they're not in violation of 
Part 97.113(d). Consider why this rule was put in place originally and 
you can see it can't apply to data files. This might actually become 
important with more people getting into multimedia.

All the transmission are point to point on the ham side, so there is no 
broadcasting involved. Note to that bullitens (messages with multiple 
destinations) are allowed in the packet system and are not considered 
"broadcasts" because all transmissions involved are two way QSOs 
(between the BBSes passing the messages and the intermediate nodes).

In general, don't under interpret the FCC regulations and don't ask the 
FCC what the rules mean, as they'll often come up with a more 
conservative ruling futher restricting experimentation in the amateur service.

Follow ups are best directed to rec.radio.ham.policy

72/73 Kevin, N7WIM / G8UDP
a-kevinp@microsoft.com

------------------------------

Date: 17 Jan 1993 21:37:07 GMT
From: sdd.hp.com!spool.mu.edu!yale.edu!ira.uka.de!rz.uni-karlsruhe.de!aifbtornado!rza@network.UCSD.EDU
Subject: BAYCOM and Linux ?
To: packet-radio@ucsd.edu

 Hello all,

 Just one Question: Did anyone succeed in running a BAYCOM Modem/TNC under 
 Linux ? (My baycom-Modem is the only reason for me to still have a dos
 bootdisk).
 
 Perhaps I can write the required software of my own, where can I get more 
 info on the way the baycom piece works?

 Any help will be greatly appreciated.

 Regards, 
 Ralf
-- 
-------------------------------------------------------------------------------
Ralf Zabka				email:	 	zabka@infpav4.kfk.de
Haid und Neu Str. 12			or	   rza@aifb.uni-karlsruhe.de
W-7500 Karlsruhe 1			phone:		    +49 721 69 72 82
----------------------------< A bug is a bug is a bug >------------------------

------------------------------

Date: Sun, 17 Jan 1993 18:29:07 GMT
From: swrinde!gatech!concert!rock!cole@network.UCSD.EDU
Subject: Problems using ka9q and activeopen PPP
To: packet-radio@ucsd.edu

Note:  this message cross-posted to both comp.protocols.ppp AND
       rec.radio.amateur.packet!!

Greetings!

I'm attempting to coax the latest release of KA9Q to dial my workstation
(running dp-2.2) and initiate a PPP link.  I've encountered two rather
significant obstacles:

1)  'ppp pp0 lcp|ipcp open active' does nothing.  The default for dp-2.2 is
to open a passive dialup session.  The two boxes could sit around forever
and never talk to each other.  I've even tried PPP between two KA9Q boxes,
one active, one passive.  Still zippo.  What am I missing?

If I open passive in KA9Q after initiating an active session on the
workstation, that at least gets the boxes talking, but the link never fully
comes up.  It apparently negotiates LCP, passes the IPCP addresses, then
gets stuck, the workstation sending the same packet over and over, KA9Q
responding with what looks to be an ACK.

2)  How in the world does the new dial command work?!?!?  I seem to recall
an article regarding Phil's link-redialing enhancements, but I'm perplexed
as to what needs to be done.  I'm used to 'dial pp0 dialer.pp0'

Please pardon my ignorance, but I'm new to PPP and it's configuration.  Any
and all help will be greatly appreciated!

Thanks,
Derrick

-- 
"Have you ever tried to clean bits of chow mein out of a keyboard?  It isn't
pretty."
                       -- unknown
-----

------------------------------

Date: 18 Jan 93 11:12:15 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!doc.ic.ac.uk!uknet!edcastle!wilde!graham@network.UCSD.EDU
Subject: rsgb gb2rs news 17th november 1993
To: packet-radio@ucsd.edu

ted@tedb.demon.co.uk (Edward Batts) writes:
>Good morning. It's Sunday the 17th of January and here is the GB2RS news
>broadcast, prepared by the Radio Society of Great Britain.

Something wrong with the Subject line here I think. :-)

Graham Rule

------------------------------

Date: 17 Jan 93 20:32:00 GMT
From: news-mail-gateway@ucsd.edu
Subject: TS140s, MFJ Multimode TNC and LSB Distortion
To: packet-radio@ucsd.edu

I would like to inquire if anyone on the list has had a similar problem to the
following:

A friend is using a TS140s and a MFJ Multi-Mode TNC connected via the
Accessory port. Like previous communications about the ts850, 950, 690
( mine) he is suffering from audio distortion if he leaves the TNC
connected when using SSB. I have solved tha problem in the past on the 690s
by effective grounding of my PK232MBX to the 690s ( thanks Dick, KD5VU).
My questions are: is the acc port on the 140s the same as the 850, 450,
690 etc or different? and - Has any one else had a similar setup with
a MFJ unit and solved it. He must stay with AFSK since I believe the 
140 does not permit FSK operation.

Replies may be sent to the list ( since the information would be
of value to those who still disconnect their TNCs prior to SSB
operation) or direct to :

SEELER@UPEI.CA

Thank you for your help in this matter ( and for solving the Kenwood
floating ground problem once again ).

David Seeler,
University of Prince Edward Island,
SEELER@UPEI.CA
VY2DCS@VE1AIC.PE.CAN.NA

------------------------------

Date: 15 Jan 93 05:21:03 GMT
From: news-mail-gateway@ucsd.edu
Subject: USING HANDHELDS ON PACKET
To: packet-radio@ucsd.edu

Date: Thu Jan 14 12:36:28 1993
Message-Id: <2439@GB7BIL>
From: G6LOH @ GB7BIL
Reply-To: G6LOH @ GB7BIL.#27.GBR.EU
To: PRAGA @ PI8VNW
Subject: USING HANDHELDS ON PACKET

someone was asking for a transformer PTT interface for Icom handhelds.
Well here is the file from the GB7BIL mods database

                   Icom Handhelds on packet
                   ========================

Most Icom Handhelds can be used on packet. This is how to achieve it.

TNC                             RIG
~~~                             ~~~
PTT-----------4.7K-------- TIP OF SMALL JACK

TX AUDIO------0.1MF------- TIP OF SMALL JACK

GROUND-------------------- BODY OF BOTH JACKS

RX AUDIO------------------ TIP OF LARGE JACK

This arrangement works with most TNC2 type clones, but it has not been tried
on the PK88.

Another possibility would be to use a 1 to 1 audio isolating transformer.
This is a suggestion on how to connect it up:

RX AUDIO---------TIP OF LARGE JACK
GROUND-----------BODY OF LARGE JACK
GROUND-----------TRANSFORMER PRIMARY
TX AUDIO---------TRANSFORMER PRIMARY
PTT--------------TRANSFORMER SECONDARY
                 TRANSFORMER SECONDARY---------TIP OF SMALL JACK

When the PTT line goes low, it makes the Tx connection for the handheld.
Having said that, on the IC24 there is a ring on the small jack that carries
+5v and you must be carefull not to short this by using a mono jack.

Julian G6LOH @ GB7BIL




PLEASE reply to the list, NOT to the From: address
because this mail is sent through a one-way gateway!

------------------------------

Date: Sun, 17 Jan 1993 19:29:21 GMT
From: usc!howland.reston.ans.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ucselx!steer!waffle@network.UCSD.EDU
Subject: Writing a packet client program?
To: packet-radio@ucsd.edu

I'm interested in writing a client program for packet. That is, instead of
using my packet controller's usual maildrop, I want software on my PC to
talk to it. I know that software exists already for this -- bbses and
whatnot -- but I'm interested in writing my own, in C, perhaps a game or
something.

I'm not too familiar with the AX.25 protocol (at least on a system level 
where a program needs to make sence out of it all!) and I'd like some
information about what needs to be handled, how to send actual stuff
over packet via my own program, etc. Has anyone done this who will give me
some pointers? Or do some docs exist on the net that can help?

Thanks in advance
Kevin kc6gwq - waffle@steer.sdsu.edu

------------------------------

Date: Mon, 18 Jan 1993 00:39:12 GMT
From: qualcom.qualcomm.com!servo.qualcomm.com!karn@network.UCSD.EDU
To: packet-radio@ucsd.edu

References <1993Jan6.093218.27598@qualcomm.com>, <1j9hqcINN9rf@matt.ksu.ksu.edu>, <1993Jan16.201038.1158@sbcs.sunysb.edu>
Subject : Re: CDMA Packet Radio (WAS Re: Who do repeater coordinators represent?)

In article <1993Jan16.201038.1158@sbcs.sunysb.edu> rick@cs.sunysb.edu (Richard Spanbauer) writes:
>	The main hitch with CDMA (code division multiple access) is that
>	the amateur radio service is allowed to use only three spreading
>	codes.  Is there work being done towards relaxing the regulations
>	on use of spreading codes?

I'm sure if there was a real need to change the rules, the FCC would
be willing to change them. There's an STA in existence right now
that waives this requirement.

Of course, there are still all the other restrictions on amateur
radio, particularly the content rules, that would be much more
difficult to change. That's why I think Part 15 (and possibly
user-provided "data PCS" on 1.8 Ghz) is where the future of packet
radio lies.

Phil

------------------------------

Date: Mon, 18 Jan 1993 00:36:27 GMT
From: qualcom.qualcomm.com!servo.qualcomm.com!karn@network.UCSD.EDU
To: packet-radio@ucsd.edu

References <1993Jan4.144520.19597@ultb.isc.rit.edu>, <1993Jan6.093218.27598@qualcomm.com>, <1j9hqcINN9rf@matt.ksu.ksu.edu>
Subject : Re: CDMA Packet Radio (WAS Re: Who do repeater coordinators represent?)

In article <1j9hqcINN9rf@matt.ksu.ksu.edu> steve@matt.ksu.ksu.edu (Steve Schallehn) writes:
>I agree that CDMA would also be great for amateur radio,
>but I thought CDMA is patented by Qualcomm.  What effects will the
>patent have on developing CDMA packet networks?

Generic, basic CDMA (i.e., multiple spread spectrum transmitters
sharing the spectrum) has been around for a long time -- since World
War 2 -- so any patents on it have long since expired.  Qualcomm's
patents cover only some very specific implementation details on
applying CDMA to cellular telephony, particularly the closed-loop
power control scheme.

I can't speak for management, but I can say that the three senior
engineering VPs are all hams, and have spoken very favorably of the
possibility of applying our CDMA system to ham radio. Of course, we
currently have our hands more than full finishing the commercial
system and getting it standardized and deployed by the industry...

Phil

------------------------------

Date: Mon, 18 Jan 1993 00:28:59 GMT
From: qualcom.qualcomm.com!servo.qualcomm.com!karn@network.UCSD.EDU
To: packet-radio@ucsd.edu

References <jstark.726853484@mcshh.hanse.de>, <9116@lee.SEAS.UCLA.EDU>, <ashok.238.727148540@biochemistry.cwru.edu>
Subject : Re: Nos (KA9Q,PA0GRI...)


The latest versions of NOS that I've released have their own built-in
terminal emulation; they no longer use ansi.sys or whatever.

The very latest version emulates a 24x80 ansi display, with most (but
I won't guarantee all) vt-100 functions as well. The generic "ansi"
termcap entry seems to work well.

I haven't done the vt100 keyboard yet, but that's on my list.

Phil

------------------------------

End of Packet-Radio Digest V93 #17
******************************
